Speakers

From Async I/O to Senders and Receivers

C++26 adds senders and receivers alongside the coroutines introduced in C++20. Why wasn't that enough? Why do we need another asynchronous programming abstraction?

This talk starts with asynchronous I/O in the operating system rather than the C++ standard library. By the time we reach senders and receivers, they should no longer seem like an arbitrary design, but the natural result of the problems modern asynchronous software has to solve.

C++26 Uncovered: Everything You Need to Know About the New Standard

C++26 is here, bringing one of the most feature-rich standards in the history of the language. This talk will uncover everything you need to know about the new standard from within—spanning core language improvements, powerful compile-time capabilities, safer programming models, and major library additions.

From compile-time reflection and design-by-contract to saturating arithmetic, SIMD, linear algebra, async execution, and new debugging tools, this talk explores the features shaping the next generation of C++. During our journey, we’ll examine not just what these features are, but why they were added, how they fit into the evolving design of modern C++, and the real-world problems they solve.

Whether you write performance-critical code, maintain large systems, or simply want to stay at the forefront of the language, you'll leave with a picture of the changes in C++26 and how to apply them effectively in your own projects!

The Compiler Knows Best

C++26 static reflection gives us something C++ developers have wanted for years: the ability to ask the compiler what it already knows.

In this talk, we’ll explore the power of static reflection through practical examples. We’ll take familiar C++ problems filled with boilerplate and compare how they look before and after reflection.

We’ll cover what is already available in C++26, how reflection can simplify code, reduce duplication, and open the door to new patterns such as enum utilities, serialization, configuration parsing, and combining reflection with #embed for compile-time data-driven code.

This talk is not just about writing less code. It is about writing clearer, safer, and more powerful C++.

From Silicon to C++26: How Hardware Shaped the Evolution of the Memory Model

For over a decade, the C++ memory model has served as the foundational contract between the language, the compiler, and modern processors. Introduced in C++11 to bring order to multithreaded execution, this abstract mathematical model has had to constantly adapt to the brutal realities of hardware physics.

This talk explores the engineering evolution of the C++ memory model through the lens of hardware constraints. We will dissect how CPU optimization mechanisms: such as store buffers, invalidation queues, and cache coherency protocols like MESI, drove the original design of memory barriers, and why abstract ideals like memory_order_consume ultimately collapsed when confronted with compiler optimization realities.

We will trace this ongoing tug-of-war across three major evolutionary milestones:

The Abstract Illusion (C++11/14): Balancing physical memory barriers against the data-dependency tracking architecture that failed in practice.

Embracing Microarchitecture (C++20/23): Moving from pure abstraction to exposing physical silicon constraints, solving false sharing with cache-line topology awareness, and replacing CPU-burning spin-locks with hardware-backed primitives like atomic::wait.

The Heterogeneous Frontier (C++26): Extending the memory model beyond CPU cores into heterogeneous execution (CPU + GPU). We will examine how std::execution (Senders/Receivers) expands formal "happens-before" relationships across hardware boundaries and weakly-ordered architectures.

Which C++ Best Practices Change When Writing Code with AI

Generative AI is shifting the C++ developer’s primary role from author to reviewer and architect. In this talk, we want to address the question: which C++ language features and best practices become more important, and which lose importance, when AI becomes the main coder.

We examine whether there are features that primarily aided the human coder and are now less critical, whether certain knowledge that was once important has become less crucial, and which features and practices have become essential for C++ developers working with AI.

Attendees will leave with:

• A practical taxonomy of C++ feature categories whose relative importance changes in an AI-centric workflow.
• A set of code-review principles that prioritize enforcement and maintainability.
• Concrete guidance on how to evolve our C++ focus so that AI accelerates delivery without eroding maintainability or correctness.

C++26 Reflection for serialization - with compile time registry

There are many reflection examples. This one focuses on the compile time generation of data to be used by a secondary process - the reader has all the information. The reflection enables to generate the in process parsing and or formatting functions. but how do we access the binary raw data from another file? how do we hold a "dictionary" of all messages types?

Impossible Types, Supernatural Guarantees

What if C++ could verify the impossible, at compile time? This talk explores how to supercharge the compiler’s reasoning with constraints that go beyond the type system, turning assumptions, guidelines, documentation and best practices into compile time guarantees.

Return to Sender: Continuation-Passing Style in C++

Continuation-passing style is a single change: nothing is returned, and the callee calls the rest of your computation with whatever actually happened. Everything else follows from it, the caller decides ownership, allocation, and thread affinity, and errors land where they occur instead of being carried home by hand. How it's built in C++, what it makes possible, and where it falls apart.

Low latency performance and how to reason with your CPU

Optimization is often considered a second pass in software development, where initially it is tempting to write your business logic out and later think about optimizing it. It has its pros and cons, but the aim of this talk is to provide you with the knowledge that will let you write optimized and fast C++ code as you go, rather than in a second pass. At worst, your optimization passes would become shorter. At best, you would be able to write out fast code in the first go, improving your ability to write efficient systems.

The talk will cover various fundamental principles and concepts useful to form a mental model of how long any given computation or operation may take, and what factors you can think of to make trade-offs while writing code. We will cover this through code examples, microbenchmarks, and looking at assembly code in godbolt. We will also discuss some principles to guide your thought process as you design your systems in an efficiency-first manner, with code examples.

After this talk, attendees would be able to intuitively guess what is a reasonable amount of time for a certain operation from a theoretical perspective. Is 10ms a reasonable time for my web server to respond with a HELLO message? Is 100us enough to compute a machine learning model’s output?

Trying to stay sane modularizing a large C++ project

One of C++20's headline features was modules, dragging C++ kicking and screaming into the modern world of #include-free source code.

Six years later, in 2026, I decided to check if the tooling was sufficiently mature, and tried to convert a large and complex software project, ScyllaDB, into C++20 modules without going completely insane.

This talk will examine whether I have succeeded.

Concepts IRL

Concepts have been in the language since C++20, and the usual pitch is readability, replacing "enable_if"s, and simplifying cryptic template errors. Both are true, and our serialization layer was a great candidate: heroic SFINAE, with template resolution that was hard to get right.

But that's not the interesting part. Working on Ceph (1M+ LoC, open source, distributed, software-defined storage system) we found three things we hadn't expected concepts to give us: decode paths that got measurably faster, whole categories of boilerplate that simply disappeared, and a latent runtime infinite loop that the compiler caught for us before it ever ran.

We'll show the real (though simplified) upstream code behind each one, the benchmark numbers across different compilers, and what adopting concepts actually looks like in an existing, large codebase.

Kill the Mutants: AI-Powered Mutation Testing with C++ Examples

Code coverage tells you which lines your tests touch - mutation testing tells you whether your tests actually care. By systematically injecting small faults (mutants) into your project code and checking whether your test suite catches them, mutation testing reveals the blind spots that line coverage hides: assertions that never fail, edge cases that slip through, and logic branches that nobody truly verified. In this talk, we will show how AI helps to generate semantically meaningful mutants that mimic real developer mistakes, intelligently prioritize which mutations matter most, and even suggest the missing tests that would catch them. You'll walk away with a practical framework for integrating AI-driven mutation testing into your CI pipeline and a new standard for what "well-tested" actually means, demostrated on C++ examples.

What C++ Never Named: Interfaces, Traits, and Mixins

Most modern languages give names to the common ways of sharing behavior across types — interfaces, traits, mixins. Developers coming to C++ often assume these concepts are missing. They aren't — C++ has all three, it simply expresses them as patterns instead of language keywords.

This talk explores interfaces, traits, and mixins from the perspective of the problems they solve rather than the syntax used to implement them. We'll examine when each abstraction is appropriate, and — critically — where the lines between them blur: a concept constraining what a mixin provides, or an interface-like contract gaining default behavior it was never meant to have. We'll then look at how modern C++ maps all of this onto familiar language features: abstract base classes, concepts, CRTP, and policy-based design.

Using practical examples — plugin architectures, reusable capabilities like comparison and serialization, and cross-cutting functionality like logging — we'll build each pattern from first principles and discuss the trade-offs involved in choosing one approach over another.

By the end of the talk, you'll have a practical mental model for recognizing and designing interfaces, traits, and mixins in idiomatic modern C++. You'll understand why these concepts are often confused — and know when each is the right tool for the job.

Building a real time OS in C++, from scratch

It's 2026, and the debate over whether C++ is a capable tool for building an operating system with should, by right, have been long settled. C++ provides a great balance between the type of low level and off-the rails work that an OS often requires with the resource tracking and automating of the menial parts that makes programming more enjoyable.

In this talk we'll discuss topics relevant for building an embedded OS, such as boot sequence, memory initialization and management and preemptive scheduling. We'll also discuss how C++ can be utilized to make these tasks easier, and in some cases also harder.

We'll also talk about the things in C++ you prefer to give up. While it is possible to have the entire scope of the language, it's not always worth the effort to re-introduce certain language components.

And most of all, we'll talk about how to do so without falling (too hard). We'll see defensive techniques that lets you know when you're stepping into an area that isn't available to you, and also how to decide whether to make it available (by re-implementing it) or just do without.

Obfuscation by Modernization: How Modern C++ Features Evade Binary Analysis

Modern C++ features like constexpr, RAII, custom memory resources, and coroutines enable developers to write expressive, high-performance code. However, the compiler-generated code for these abstractions often produces complex binary structures that obscure program intent, disrupt control-flow graphs, and evade traditional security analysis tools.

This talk explores the concept of "obfuscation by modernization" how modern C++ language constructs manifest at the assembly and binary level to create stealthy execution patterns without using traditional packers or obfuscation tools. We will examine how constexpr metaprogramming strips data artifacts, how coroutine state machines dismantle linear control flow, and present a practical case study demonstrating how a custom modern C++ architecture evades modern heuristic and endpoint detection (such as Microsoft Defender). Attendees will gain a deep, under-the-hood understanding of what modern C++ compilers actually produce when language features are pushed to their limits, and how reverse-engineering tools (including AI decompilers) interpret these abstractions.

Target Audience & Prerequisites

Audience: C++ developers, systems software engineers, and security/reverse engineering analysts interested in compiler output, binary analysis, and low-level code generation.

Prerequisites: Intermediate C++ knowledge (comfort with modern C++ constructs like templates, smart pointers, and basic assembly/system API concepts). No prior malware analysis experience required.

C++ Under the Hood: Internal Class Mechanisms

This talk will examine the internal C++ mechanisms around the topics of:

• The C++ onion as it relates to construction, polymorphism, and memory footprint
• Order of object construction & destruction, and pre- & post-main() processing.
• Member Function Pointers (not your father’s C function pointer),
• Member Data Pointers (not raw pointers) (data-morphic functionality)

Why Your Tests Still Miss C++ Bugs: Valgrind, Sanitizers, and Runtime Debugging

Even strong test suites miss memory corruption, data races, undefined behavior, and other bugs that only appear at runtime. This talk shows how to use Valgrind and compiler sanitizers such as ASan, TSan, and UBSan to expose those failures early, understand the reports they produce, and turn them into actionable fixes. We will compare the strengths, blind spots, and performance costs of each tool, and show how to combine them in a practical workflow for development, CI, and regression testing. The talk draws on practical, real-world experience, in complex systems, multithreaded code, debugging real issues.The examples will focus on real C++ code and on the kinds of failures that matter in large systems, embedded software, and multithreaded applications. By the end, attendees will know when to reach for each tool, how to read the results, and how to make dynamic analysis part of everyday engineering rather than a last resort.

Processor Design and C++ Memory Models

std::atomic and std::memory_order are utterly opaque abstractions. It feels like they were put in place to hide some monstrosity that is too complex for mortals to comprehend, and inevitably when trying to understand the underlying reality, the explanations end with 'the processor does weird things' and 'think about it as if...'.

Well, 'think about it as if' no more. In this talk we'll present the gory and wonderful mechanics of cache coherence protocols, store buffers, cache invalidation queues and the in-processor load-store-queue. We'll explain how modern hardware design makes different cores have different views of memory, and what fences and read-modify-write instructions do exactly - for both x86/64 and ARM/RISC-V (which can be dramatically different).

This is an advanced low-level talk located at the borderline of software development and electrical engineering, discussing topics rarely - if ever - discussed at C++ conference talks.

Running C++ on Bare Metal: Building an aarch64 Cross-Toolchain from configure to First Boot

We often see C++ running atop an operating system and a heavy standard library. But how can we run it on a processor with nothing underneath it?

This talk walks through the entire pipeline to get modern C++ running on a bare-metal 64-bit ARM (aarch64) target inside QEMU.

We start by bootstrapping a clean aarch64-none-elf GCC and Binutils cross-toolchain (from source) with libgcc, but no C library. We'll see which configure options matter, why the -none-elf target is the simpler one to build, and what libgcc quietly provides that your code won't link without. We make the distinction between the compiler's runtime (libgcc) and a C library (i.e. glibc or newlib).

We'll wrap up by showing the payoff, which is a small printk ring buffer, a stack-allocated string, and containers that live without a heap, all written in C++.

Relevance

Reaching for an OS is a reflex, but plenty of real systems don't necessarily need one. When a device does a single, well-defined job, a full Linux or even an RTOS like FreeRTOS can be more than the task requires. That question was discussed in Core C++ 2024 "Optimizing Embedded Software Infrastructure" by Alex Kushnir and Akram Zoabi (YouTube). Our talk provides a practical continuation for the path of bare-metal.

Intended Audience

Anyone who might ship C++ onto bare hardware: embedded and firmware developers, people building safety-critical systems, or just C++ programmers who want to see the machine one layer down.

No prior kernel experience is assumed. The ability to read solid C++ is enough.

When a Broken Clock Is Right 23 Times a Day

Timing bugs are easy to write, hard to test, and often nearly impossible to reproduce on demand. They can affect any software, but C++ is frequently used in systems where time is measured at very high resolution, hardware and platform details matter, and—in real-time systems—even a small delay can become a failure.

From subtle arithmetic and conversion errors to undefined behavior and clocks that wrap, stall, drift, or disagree, seemingly reasonable timing code can behave in surprising ways. This talk explores these hidden traps and the practical techniques that help keep clocks, timers, and deadlines under control.

Implementing a New Kind of Static

Ever wondered how a modern C++ compiler looks from the inside?

This session will help you to get familiar with llvm clang in a simple, intuitive way.

We will start from going through clang structure and then implement a small feature: a new static that is shared between function template instantiations.

At the end, you will see that while compiler engineering is complex, starting with it can be beginner friendly!

Forkable MicroVMs for Agent Workloads: Snapshots, Isolation, and Fast Resume

Coding agents need fast, disposable, fully isolated compute, and open infrastructure already has most of the pieces. This talk builds an agent execution layer on open primitives: KVM, snapshot and restore, virtual networking, and storage built for fast clone and teardown. We cover image lifecycle, scheduling many short-lived agent workers, and observability across a fleet of disposable microVMs. Every piece is open and portable, no proprietary platform required.

Structured Binding Assignments (P3817)

The talk describes the C++ language feature, the path to standardize it and its experimental implementation in clang.

The feature in a nutshell:

int ar[2] = {42, 43};
int y;
auto [x, using y] = ar; // x is new, y is assigned

From Unit to Production: A Three-Layer Approach to Performance Measurement in C++ AWS Services

Performance problems are easy to spot and hard to diagnose — especially when your C++ service runs on elastic cloud infrastructure. This talk presents a three-layer measurement framework (Catch2 → k6 → Datadog) that leaves little room for guesswork, with practical lessons from real AWS workflow tuning and the surprises that only numbers can reveal.

Our Journey Toward a Fully Backward-Compatible, UB-Safe ISO C++

Today's world runs on C++. That's because, in domains requiring scale, performance, low latency, and fine-grained control over concurrency, C++ is second to none! Yet in recent years, a growing concern has emerged: C++ programs are often considered unsafe — not because of programmer negligence, but because the language itself provides insufficient mechanisms to prevent or reliably detect undefined behavior (UB). For those financially and technically invested in C++, its current lack of language safety raises a fundamental question: How can we evolve ISO C++ to be UB-safe without necessarily sacrificing runtime performance, and without breaking backward compatibility with existing, valid C++ code?

In this talk, we begin by motivating an overall approach to UB-safety that starts from a simple but uncompromising premise: each individual potential source of UB must be able to be detected via runtime checking. Crucially, this approach eliminates the notion of "safe" and "unsafe" regions of a program — there is no place where UB can hide, and no need to switch languages, subsets, or tools to achieve comprehensive coverage.

We then examine how the C++26 contracts facility provides the essential foundation for transforming optional runtime checks into the practical, scalable mechanism for eliminating UB bugs in production software. Contracts give developers fine-grained control over where and when checking occurs, allowing runtime overhead to be spent where it is affordable or most valuable — such as in new, rarely executed, or security-critical code. These decisions naturally evolve over time, as frequent, long-running checks that never fire may no longer justify their cost.

Finally, we outline the concrete steps of an incremental journey toward reducing undefined behavior in ISO C++. The result is a model of UB-safety — rooted in C++26 contracts and optional runtime checking — that is competitive with, and in key respects stronger than, approaches taken by other high-performance languages. Most importantly, this model applies not only to new code, but to the vast body of existing C++ software already in the wild.

Is C++ Turing Complete?

Everyone knows that C++ is Turing complete. That turns out to be almost the least interesting answer. How many different languages are hiding inside C++, and how many of them can compute anything on their own?

In this fast, playful tour, we make ordinary runtime C++, templates, constant evaluation, class template argument deduction, reflection, contracts, and the preprocessor each do universal computation—or say precisely where the machine boundary lies. Rule 110 turns the preprocessor into a delightfully unlikely computer. A new CTAD construction finds recursion where no sensible person would look for it. C++26 adds two more surprises.

No computability theory background is required. We will build one small proof toolkit, then use it repeatedly as the reveals get stranger. The full proofs are there for anyone who wants to descend into them; the main path stays visual, quick, and fun. By the end, the question will not be whether C++ is Turing complete, but how it keeps happening.

Back to Basics: Abstractions

Abstraction is one of the most powerful tools in software engineering, design, and development. C++ provides a rich set of mechanisms for building effective abstractions, starting from classes for encapsulation – hiding data and exposing only the required behavior, interfaces for separating contract from implementation, templates for generic programming, C++20 concepts for expressing type expectations, function objects and lambdas for flexible callables, and patterns such as RAII for encapsulating behavior over a given control flow.

We rely on abstractions to write generic and reusable code, yet we often struggle to recognize when they clarify intent and when they quietly make systems more fragile.

In this Back to Basics talk, we return to the fundamental principles of C++ abstractions. We explore how good abstractions enable us to write code in "future tense": implementing components before all requirements are known, composing systems incrementally, and deferring decisions without sacrificing correctness. We also examine how well-designed abstractions improve testability.

Through concrete examples, we contrast good and bad abstractions, highlighting common pitfalls such as over-generalization, leaky interfaces, and premature constraints, and show how to design abstractions that remain robust and useful over time. Finally, we discuss how good abstractions contribute to more effective AI-generated code.

Whether you are a novice C++ developer or a more experienced one, this talk will help you sharpen your intuition for abstractions that stand the test of time.

Effective Lock Free Architecture in C++26

Achieving optimal performance on multi-core systems frequently relies on careful management of critical sections, and on using lock-free mechanisms wherever possible. On 2026 the C++ standard library gained 2 mechanisms for safe reclamation, that enable robust and high performant lock-free systems:

• RCU
• Hazard pointers

In this talk we will learn about the need for safe reclamation, understand why the are important, and dive into the two new mechanisms, along with other alternatives - and understand the best scenarios to use each of them. If you care about performance of complex multi threaded systems and want to understand why reclamation is important, please join me.

Thinking Low Level, Writing High Level

Software systems engineering is a hierarchy. There are layers of abstractions, ideally non-leaky layers. There is a gap between how a software system appears from the perspective of a high level language, and from the perspective of what the underlying platform would expect for a target of performance. An overview of contemporary hardware platforms and how software engineering and design practices and methodologies could help in building performing systems, with a particular focus on low level optimizations while maintaining higher level focus and abstractions.

There is a trend of moving software engineering focus upward to constructs that have a tendency of hiding the specific of the underlying platform – and there certainly are very good reasons for such a paradigm change. Performance matters. Premature optimization is evil. Is there anything in between those two extremes? How feasible is it to rely on the abstraction of the platform as hidden by the compiler and the corresponding libraries, expecting that it will do the right thing? How much of hints and specifics would one need to expose for the compiler to be able to do the right thing? What is the right balance between expressing application logic via higher level construct yet still being able to gain the performance benefits as if relying on the low level specifics?

Then there are language abstractions. Abstractions are good. They tend to hide the details that otherwise might be hard to get right, they provide for a feeling of certain constructs being simpler, and they appear to just work. Moreover, they appear to just work with no additional cost, at least on paper. Is it really the case? Let’s take a look and see. This is a look inside workings of several areas of machinery that is commodity in practical software engineering – error handling, working with data collections, and simplification of control flow. An analysis of how higher level abstractions map to lower level language constructs and at what cost, and an equivalent functionality match to “simpler” options from the perspective of performance and engineering cost, and the impact to data structures and overall application design – those would be the main areas of coverage of this part of the talk.

Overall the talk has separate intertwined sections, each one focusing on logically separate set of topics, giving priority to techniques and specifics relevant to single thread performance. There is little specifics of any particular higher level language as all contemporary ones support an equivalent set of functionality, instead the content is structured to look into the output of a compiler and why particular output may impact the resulting performance, and what could be done for changing it. Given the conference on C++, most of the content and examples are specific to C++, although the content is equally applicable to C, Rust, Zig, Go, and the main message is on the technologies and mechanics, and not on just the language.

It might be that the layers of abstraction need to be quite leaky.